Fix parsing of empty long option values - #959
actuallyhrishikesh wants to merge 1 commit into
Conversation
|
how does this compare to #961 |
|
Thanks for pointing this out. I hadn’t seen #961 when I opened #959. They appear to address the same underlying issue: preserving the presence of = for long options even when the attached value is empty, so that the following positional argument isn’t consumed. My #959 focuses on treating --output= as an explicit empty attached value, with tokenizer and end-to-end regression coverage. #961 addresses the same issue by explicitly tracking whether = was present in ParsedArgument.init(_:). Given the overlap, I’m happy to defer to whichever implementation you think fits the codebase better. |
|
@actuallyhrishikesh Thanks for this PR – really appreciate the contribution! We're going to go with the solution in #961 instead, as I think that interpretation of the command-line arguments will be more useful for CLI tool users. |
3 participants
Fixes #958.
This change treats the presence of
=in a long option as an explicit attached value, including empty values.For example:
--output=
is now parsed as an option with an empty string value rather than being treated as a bare flag.
Tests:
--output=.Compatibility note:
--flag=is now treated as a flag with an explicit empty attached value, consistent with the existing single-dash-f=behavior and the issue's explicit=rule.